System And Method To Reduce Disk Access Time During Predictable Loading Sequences

ABSTRACT

A method, software, and system for loading data from disk include comparing a current sequence of disk I/O requests to data indicative of a previous disk I/O request sequence. Responsive to detecting a match between the current disk I/O sequence and the previous disk I/O sequence, a copy of data blocks accessed during the I/O sequence is stored in a contiguous portion of the disk. Responsive to a subsequent request to data in the disk sequence, the request is mapped to and serviced from the sequential portion of the disk. In one embodiment, the disk sequence represents a boot sequence of the system.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application of and claims priorityfrom U.S. patent application Ser. No. 10/798,091, filed on Mar. 11, 2004and U.S. patent application Ser. No. 11/760,821 filed on Jun. 11, 2007.

BACKGROUND

1. Field of the Present Invention

The present invention is related to the field of data processing devicesand specifically to data processing devices that employ fixed diskstorage.

2. History of Related Art

Microprocessor-based data processing systems are composed of severalsubsystems or major components. Three of these subsystems that have themost affect on system performance are the central processing unit (CPU),the system memory, and the file subsystem. Of these three, however, thefixed disk storage used by the file subsystem has the most significantimpact on system performance. The predominance of the fixed disk unit'saffect on system response time is due to the presence ofelectromechanical elements in the fixed disk unit. Whereas semiconductorprocessors and memory have no moving parts and operate at speedsdetermined by the speed of electrons moving through an impedanceelement, disk units are characterized by mechanical latencies caused byrotation of the media and/or movement of the head (i.e., seek times).Latencies associated with disk accessed time can be reduced by using adisk cache. Like its cache counterpart in the context of system memoryhierarchies, a disk cache is a relatively small, fast, and expensivestorage medium into which recently retrieved data from the disk can bestored in anticipation of the data being required in the near future.For disk sectors that are accessed frequently, disk caches can yieldsignificant performance benefits.

Unfortunately, a disk cache can only be useful after it is populatedwith data. When a system is first powered on or reset, the disk cache isempty. Thus, the great majority of data accesses that occur following arestart can only be fulfilled from the fixed disk. This problem might beacceptable if relatively few disk accesses were needed followingrestart. In reality however, the system restart of most data processingsystems, including all x86-based data processing systems that run aWindows® platform, execute a large number of disk request followingrestart. These disk request are needed to retrieve portions ofincreasingly complex operating systems from disk and store them intomemory. Files on disks are typically allocated sequentially when theyare installed. When accessed (data files) or executed (program files),it is relatively rare that an entire file is used. During a bootsequence, for example, large portions of software such as the operatingsystem's help files are not accessed. In addition, during bootsequencing, a reference to an entity in one file frequently invokesanother file that may reside on a portion of the disk storage that isphysically distant from the calling program. For at least these reasons,the boot sequence is characterized by frequent accesses to disk storagewhere there is substantially no relationship between the data requestedin each access. In contexts other than system boot sequencing, it may becommon to detect a disk access sequence that is repetitive. In suchcases, it would be desirable if the repeated nature of the requestscould be recognized by creating an entirely sequential (contiguous) copyof the requested data and a mapping from the original data sequence ofthe relocated data sequence such that, during a subsequent access tothis data, the requested data would lie in a contiguous portion of thedisk.

SUMMARY OF THE INVENTION

Generally speaking, the present invention is concerned with improvingdata processing system performance by reducing the amount of time asystem consumes accessing its fixed disk storage. The invention is mostapplicable to sequences or patterns of fixed disk access that occurrepetitively and predictably. The data processing system includes afixed disk controller that is enabled to monitor and record diskaccesses (i.e., what tracks and sectors are requested). When the diskcontroller detects a sequence that has previously occurred one or moretimes, the disk controller is configured to copy the various disksegments comprising the sequence into sequential space in a dedicatedportion of the disk. If the data in the sequence is accessed later, thedisk controller reroutes the requests into the relocated portion of thedisk, where the data is stored sequentially. Because the data is storedsequentially in the dedicated portion, the disk spends less time movingthe disk head among disk portions that are randomly spaced on the disk.In addition, because the relocated data is sequential, the diskcontroller can employ and greatly benefit from pre-fetching data into adisk cache, either on the disk controller or elsewhere. In oneembodiment, the invention is applied to a system boot sequence, wherethe disk access sequence is likely to follow a pattern. In otherembodiments, the invention is implemented in conjunction with post-bootdisk access sequences such as the sequence that is followed when anapplication program is loaded.

BRIEF DESCRIPTION OF THE DRAWINGS

Other purposes and advantages of the invention will become apparent uponreading the following detailed description and upon reference to theaccompanying drawings in which:

FIG. 1 is a block diagram of selected elements of a data processingsystem suitable for implementing the present invention;

FIG. 2 is a flow diagram of a method of recording, detecting, andcopying a predictable disk access sequence according to an embodiment ofthe present invention;

FIG. 3 is a flow diagram of a method of monitoring I/O requests andservicing the request from relocated data according to an embodiment ofthe present invention;

FIG. 4 is a conceptual representation of fixed disk storageconfiguration according to an embodiment of the present invention; and

FIG. 5 is a block diagram of selected elements of a disk controlleraccording to an embodiment of the present invention.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription presented herein are not intended to limit the invention tothe particular embodiment disclosed, but on the contrary, the intentionis to cover all modifications, equivalents, and alternatives fallingwithin the spirit and scope of the present invention as defined by theappended claims.

DETAILED DESCRIPTION OF THE INVENTION

Turning now to the drawings, FIG. 1 is a simplified block diagram of adata processing system 100 suitable for use in conjunction with oneembodiment of the present invention. In the depicted embodiment, system100 includes one or more central processing units (CPU's) 102-1 through102-n (collectively or generically referred to herein as CPU(s) 102).CPU(s) 102 share a system bus 104 that provides access to a systemmemory 110 via a bridge/memory controller 106. An I/O bridge 120connected to memory controller bridge 106 provides connections to afirst I/O bus 130 and a second I/O bus 140. In the depicted embodiment,the system's basic I/O system (BIOS) firmware is stored on a nonvolatilestorage device such as a flash memory device represented by referencenumeral 135. First I/O bus may be an conventional expansion bus such asthe Industry Standard Architecture (ISA) bus or a variant thereof. Inother implementations, first I/O bus 130 is a low pin count (LPC) bus.

The second I/O bus 140 is likely an industry standard peripheral bussuch as the Peripheral Components Interface (PCI) bus. As depicted inFIG. 1, a controller 145 connected to second I/O bus 140 is connected tofixed disk storage 150. Controller 145 may be implemented as a singledisk controller or as a Redundant Array of Inexpensive Disks (RAID)controller in an embodiment where fixed disk storage 145 represent aRAID array. RAID is a well known technique for providing redundancy infixed disk storage.

When a data processing system such as system 100 is first booted, systemmemory 110 and any CPU cache memory (not depicted) contain no databecause they are volatile storage elements that lose their data contentwhen a system is powered off or reset. To transition from a state inwhich there is no program code stored in its volatile storage, system100 must execute code stored in nonvolatile memory.

The code that is first executed following a power on or system reset iscommonly referred to as the boot code. The boot code is primarilyresponsible for performing certain critical functions includingestablishing the BIOS, performing a basic self test (referred to as thepower on self test (POST), and loading an operating system that can thenassume control of the system's operation. Because the volatile storageelements are “empty” following reset and because the firmware device 135likely has severely limited storage capacity, the bulk of the code thatis fetched during the boot sequence (such as the operating system codethat must be loaded into memory) is retrieved from fixed disk storage150. Retrieving data from fixed disk storage is notoriously slowcompared to retrieving data stored in other storage elements such assystem memory 110. Fixed disk 150 is characterized by mechanical andelectromechanical elements that must be operated to retrieve data fromthe disk. Most significantly, the disks read/write head must bepositioned over the appropriate track and sector of the appropriate diskbefore the data can be accessed. If data from two physically disparateportions of the disk are accessed in close chronological succession,performance will be impacted negatively by the time required to rotatethe disk from the first portion of the disk to a second portion and movethe read heads.

In at least some applications of significance in terms of the frequencyof occurrence or in the amount of data that they retrieve, the dataaccess pattern associated with certain events does not varysignificantly from one execution to another. Among these applications,perhaps the most recognizable is the boot sequence itself. The bootsequence of many data processing systems does not vary in anysubstantial way from one power on or reset event to the next. Inaddition, the boot sequence is likely to involve many accesses to fixeddisk storage and there is no necessary relationship between the dataaccessed during the boot sequence and the data's position on the disk.Thus, the boot sequence may invoke a sequence of disk access to dataportions that may be widely scattered over the physical disk therebyrendering the boot sequence highly inefficient in terms of access time.The present invention addresses this problem by recognizing andrecording a disk access sequence, such as the disk access sequence thatoccurs during the boot sequence. When a sequence is determined to be asequence that has been repeated in the past (i.e., the sequence has asignature), the disk controller copies or relocates the data that wasaccessed during the sequence into sequential storage on a dedicatedportion of the fixed disk. This relocated data is then used duringsubsequent occurrences of the disk access sequence.

Portions of the invention may be implemented as a set or sequence ofcomputer executable instructions (software) that is stored on a computerreadable medium such as a magnetic disk or tape, a CD ROM, a flashmemory or other electrically alterable medium. During times when theinstructions are being executed by a CPU, portions of the software mayreside in system memory or a cache memory of the CPU.

Referring now to FIG. 2, a flow diagram illustrating a method 200 ofmonitoring disk accesses patterns or sequences for a characteristicsignature is depicted. In the depicted embodiment, a disk accesstracking is mode is enabled (block 202) as an initial step in the datarelocation process. In one embodiment, the system's disk controller 145is primarily responsible for tracking disk accesses patterns. In suchembodiments, disk controller 145 has a configurable “record” mode duringwhich I/O accesses to fixed disk 150 are recorded in storage (notdepicted) on disk controller 145. Disk controller 145 preferablyincludes some random access memory (RAM) storage capacity to store diskaccess sequences. When disk controller 145 is in a record mode, each I/Orequest to fixed disk storage 150 is recorded. The record informationincludes, at a minimum, the head, track, and sector number of the datarequested. The disk access information is recorded in the same order asthe disk access requests themselves. In this way, disk controller 145builds a sequential table of disk access data representing the sequenceof I/O requests that are made to fixed disk storage 150.

Recording of disk access requires some processing overhead on the partof disk controller 145 and some storage capacity to store the recordedsequences. In many applications, disk controller processing bandwidthand disk controller storage are in short supply. In such cases, it isdesirable to implement disc controller 145 with a record switch that maybe toggled under software control so that disk I/O requests are notrecorded all of the time, but instead, only when desired by the user oradministrator. As indicated previously, a primary candidate forrecording disk access sequences is the sequence of disk accesses thatoccur immediately following system power on or reset until the time whenan operating system is loaded and has control of the system. Becausethis code sequence is the first code sequence to execute followingreset, one embodiment of the invention employs a disk controller 145having a record “switch” that is always on at power up. In thisembodiment, the disk controller is capable of recording from the as soonas the system is powered on.

With disk access tracking enabled in block 202, the disk controller thenbegins to record (block 206) the sequence of access to fixed diskstorage 150. Disk controller 145 may include or allocate dedicatedstorage for storing disk access sequences. Depending upon the amount ofinformation stored with each disk access request, the amount of storagerequired for this task varies widely. In an embodiment designed tominimize the amount of storage required to store a sequence of I/Oaccesses, a minimum of information is stored for each disk accessrequest. In this context, a minimum of information would likely includethe physical address (head, track, sector, etc) of the first sectoraccessed with the I/O request and the amount of data requested.

At some point, due to lack of storage, the performance impact ofrecording, or some other concern, it may be desirable to disable diskaccess recording. Disk controller 145 according to at least oneembodiment of the invention includes a switch (software or otherwise)that disables I/O access recording. Knowing when to stopping recordingusing the switch may be more difficult than knowing when to start it. Asmentioned above, starting the recording is achieved by default followingsystem boot or through manipulation by the system administrator or otherperson. Knowing when to disabled recording, however, is complicated bythe fact that an operating system, as such, never completes executing.Operating system's in one sense are monitoring programs that remainactive as long as the system is active. Because the operating systemnever really turns off, it is difficult to tell the system in any waythat is meaningful when to stop recording.

In the context of an initial boot sequence, turning off I/O accessrecording is likely to occur when the operating system is loaded. Thispoint in time or sequence may be detected by, for example, monitoringfor the first user input that is received or monitoring for a lapse oftime exceeding a specified threshold that passes without any user inputor I/O access requests.

As illustrated in FIG. 2, disk controller 145, monitors for a diskaccess signature (i.e., a sequence that it has recorded on a previousoccasion). Until at least one sequence of disk access is stored diskcontroller 145, the controller cannot recognize another sequence as amatching sequence. Thus, disk controller 145 must record and store atleast one sequence of I/O requests for comparison with subsequent diskaccess sequences. In one embodiment, the system boot sequence is thefirst sequence that is recorded and stored for comparison with asubsequent sequence. When checking for a matching sequence in block 208,disk controller 145 may place limits on the amount or quantity of codethat must match before the code sequence is recognized as a signature toprevent very short sequences of disk accesses that match from beinginterpreted as a signature.

If a disk access sequence is recognized (block 208) as matching asignature that the disk controller has seen in the past, the disccontroller will disable (block 212) disk access recording or trackingand initiate (block 216) a “relocation” process in which the disksectors that were accessed during the sequence recognized as matching asignature are copied from their original disk locations into dedicatedportion of the fixed disk referred to herein as the disk's signaturepartition.

Referring momentarily to FIG. 4, a conceptual representation of animplementation of a fixed disk storage area according to one embodimentof the present invention is depicted. In the depicted embodiment, fixeddisk storage 150 is allocated into different partitions. At the rootsector (track 0, sector 0), a master boot record (MBR) program 410 usesa partition table 412 to determines where the partitions are and todetermine which partition is the active partition. Partition table 412defines the physical partitioning of disk 150. In the illustratedimplementation, a first partition 421, which typically begins in track 0and includes all contiguous disk space up to the end of partitionindicator 423 in Track 1. In a likely implementation, first partition421 is associated with a particular operating system. When the MBRP 410executes and recognizes first partition 421 as the active partition, itinvokes a boot record on first partition 421 that performs the processof loading into memory the operating system that is resident on firstpartition 421. This loading process is illustrated in FIG. 4 by a set ofdisk blocks 401-1 through 404-1. As the boot record on first partition421 executes, the disk segments represented as 401-1 through 404-1 areloaded into memory in a chronologically sequential manner. It is notedfrom FIG. 4 that the different blocks retrieved during the boot sequencemay be located on different tracks, distant sectors, and so forth. Itwill be appreciated by those skilled in the operation of fixed diskdrives that the sequential retrieval of blocks 401-1 through 404-1 willincludes a significant amount of delay as the disk read/write elementsare rotated and otherwise positioned over the respective segments.

According to the present invention, however, the sequence of accesses todisks 401-1 through 404-1 is monitored and recorded. When the sequenceis subsequently encountered (on the next system boot for example), thesystem will recognize the sequence as defining a signature and relocatethe blocks in the signature to a sequential area of the disk identifiedas signature partition 430. Although the depicted embodiment elects tostore the relocated data into a different partition than the partitionin which the original data resides, other embodiments may use portionsof first partition 421 to store any signature(s) associated with thatpartition.

Returning to FIG. 2, disk controller 145, after relocating data from itsoriginal location to the signature partition 430 (or other sequentialarea of the disk) maintains a mapping between the original data's diskaddresses and the relocated data's disk addresses. By maintaining amapping from the data original location to its location within signaturepartition 430, the invention enables subsequent accesses to the originaldata to be “routed” to the sequential partition 430. In block 220 ofFIG. 2, this routing functionality is enabled after all (or at least aportion) of data that was determined to be a part of the signature isrelocated to the signature partition 430.

The flow diagram of FIG. 2 illustrates the method of detecting asignature and relocating the data to a sequential segment of the fixeddisk storage. After the routing functionality of disk controller 145 isenabled, disk accesses are performed according to the method 300 of theflow diagram of FIG. 3. Specifically, disk controller 145 monitors(block 302) all disk I/O requests once its router functionality isenabled. When an I/O request is detected in block 304, the diskcontroller determines (block 308) whether the requested disk sector isin the signature. The disk controller can make this determination bycomparing the requested disk sector to those sectors defined in itsrouting information.

If the requested segment is determined (block 312) by the diskcontroller to be a disk sector that is stored in the signaturepartition, the disk controller will invoke its router functionality toretrieve the data from the sequential partition. One of the advantagesof storing data sequentially in the order that it is accessedchronologically is that doing so greatly improves opportunities forprefetching data. Prefetching refers to a technique used to reducedelays by anticipating (guessing) what data will next be needed from adisk and placing this data in the disk controllers disk cache, which istypically just a RAM array. The benefit to having the data arrangedsequentially in signature partition 430 is that prefetching data islikely to prefetch data that will soon be used.

With prefetching enabled, the embodiment of method 300 depicted in FIG.3 includes determining not only whether the requested data is in thesignature partition, but also determining (block 316) whether therequested data is in a disk cache of disk controller 145. If the data isin a disk cache, disk controller 145 retrieves the requested data fromthe disk cache thereby saving significant access time. If the data isnot currently in the disk cache, the disk controller will fetch (block324) the data from the signature partition and cache the data in a diskcache (also referred to as a buffer) of fixed disk 150.

Referring now to FIG. 5, selected elements of disk controller 145according to one embodiment of the present invention are depicted toillustrate the routing functionality described above. Disk controller145 according to the depicted embodiment includes a disk router 520 anda disk cache (buffer) 504. When disk controller 145 receive an I/Orequest, such as the depicted request for data block 401-1, it consultsa mapping (not depicted) within router 502 to determine if the requestedblock is part of the signature partition. If the request is for arelocated data block (i.e., a data block that has been copied intosignature block 430), router 502 determines if the data is currentlystored in disk cache or buffer 504. If the requested data “misses” indisk cache 504, routers 502 will forward a request for the relocateddata block 401-2. In the depicted embodiment, disk controller 145 will,in addition to requesting relocated data block 401-2, which is currentlyneeded, but also request a prefetch of data block following block 401-2(i.e. 402-2 and so forth). By prefetching data when block 401-2 wasretrieved, the disk controller 145 tries to improve the amount of timespent accessing those subsequent blocks. Thus, if a request for data401-2 follows the request for data block 401-1, the router 502 will mapthe request into a request for data block 401-2, which will be servedfrom the disk cache buffer 504 rather than from the disk directlythereby reducing the access time. Even in cases where the requested datais not found in buffer 504 due to its limited size, the request will beserviced from the signature partition 430. Because the signature data isstored sequentially in the signature partition, the data can be accessedfaster due to the close physical proximity of all the data in thesignature partition.

It will be apparent to those skilled in the art having the benefit ofthis disclosure that the present invention contemplates a method forarranging the fixed disk to improve the performance during a sustainedfixed disk access sequence. It is understood that the form of theinvention shown and described in the detailed description and thedrawings are to be taken merely as presently preferred examples. It isintended that the following claims be interpreted broadly to embrace allthe variations of the preferred embodiments disclosed.

1. A method of loading data from disk in a data processing system,comprising: comparing a current sequence of disk requests to dataindicative of a previous sequence of disk requests; responsive todetecting a match between the current sequence and the previoussequence, storing a copy of data blocks accessed during the currentsequence in a contiguous portion of the disk; and responsive to asubsequent request for data in the disk sequence, mapping the request tothe sequential portion of the disk and servicing the request from datain the sequential portion.
 2. The method of claim 1, further comprisingrecording a sequence of disk accesses, wherein recording the sequenceincludes recording the disk address of each block accessed and thelength of each block.
 3. The method of claim 1, wherein storing a copyof data blocks accessed during the I/O sequence comprises storing thedata blocks sequentially in the order that the data blocks were accessedchronologically.
 4. The method of claim 3, further comprising,responsive to retrieving data from the contiguous portion, prefetchingadditional data from the contiguous portion of the disk and caching theadditional data in a buffer.
 5. The method of claim 4, furthercomprising, responsive to an I/O request, determining whether the datarequested resides in the buffer and, if so, retrieving the data from thebuffering without accessing the hard disk.
 6. The method of claim 1,wherein the sequence of disk requests includes the sequence of diskrequests following a power-on event.
 7. The method of claim 1, whereinthe contiguous portion of the disk to which the data is copied is on adifferent partition of the disk than a disk partition on which theoriginal data is stored.
 8. A computer program product, comprising asequence of computer executable instructions stored on a computermedium, for booting a data processing system, the program productcomprising: program code means for recording a sequence of accesses todisk storage during a system boot sequence; program code means forcopying data blocks accessed during the boot sequence into a contiguousblock of the fixed disk; and program code means for routing, during asubsequent boot sequence, the sequence of disk accesses to a sequence ofaccesses to data in the contiguous block wherein the data retrieved fromdisk during the subsequent boot sequence is retrieved from thecontiguous block.
 9. The computer program product of claim 8, furthercomprising recording a sequence of disk accesses, wherein recording thesequence includes recording the disk address of each block accessed andthe length of each block.
 10. The computer program product of claim 8,wherein the program code means for copying data blocks accessed duringthe boot sequence includes copying data blocks accessed during the bootsequence to the contiguous portion in the order that the blocks wereaccessed chronologically.
 11. The computer program product of claim 8,wherein the contiguous portion of the disk to which the data is copiedis on a different partition of the disk than the original data.
 12. Thecomputer program product of claim 8, further comprising code means forprefetching data during the subsequent boot sequence and storing theprefetched data into a buffer wherein at least some of the disk requestsof the subsequent boot sequence are serviced by the buffer withoutretrieving data from the disk.
 13. The computer program product of claim8, further comprising code means for updating, in response to amodification of data in the boot sequence, of updating the data in boththe original data block and the copied data block.
 14. A data processingsystem, comprising: a processor coupled to a system memory; a diskcontroller coupled to the processor and memory, and configured tocontrol accesses to disk storage of the system, wherein the diskcontroller is configured to: record data indicative of a sequence ofdisk sectors accessed during operation of the system; copy the sectorsaccessed during the sequence into a contiguous block of the diskresponsive to detecting the same disk access sequence occurring; andresponsive to a subsequent access to a disk sector in the sequence ofdisk sectors, servicing the request from the contiguous block.
 15. Thesystem of claim 14, wherein the sequence of disk accesses represents thesequence of disk accesses that occur following power on.
 16. The systemof claim 14, further comprising recording a sequence of disk accesses,wherein recording the sequence includes recording the disk address ofeach block accessed and the length of each block.
 17. The system ofclaim 14, wherein the program code means for copying data blocksaccessed during the boot sequence includes copying data blocks accessedduring the boot sequence to the contiguous portion in the order that theblocks were accessed chronologically.
 18. The system of claim 14,wherein the contiguous portion of the disk to which the data is copiedis on a different partition of the disk than the original data.
 19. Thesystem of claim 14, further comprising code means for prefetching dataduring the subsequent boot sequence and storing the prefetched data intoa buffer wherein at least some of the disk requests of the subsequentboot sequence are serviced by the buffer without retrieving data fromthe disk.
 20. The system of claim 14, further comprising code means forupdating, in response to a modification of data in the boot sequence, ofupdating the data in both the original data block and the copied datablock.